Was macht ein Software-Architekt?
Die Rolle des Software-Architekten kann verschiedentlich interpretiert werden: Technologieplaner, Change Manager, Chefentwickler, Projektkoordinator, Kommunikator, Kundenberater, etc. Worauf kommt es dir persönlich in deiner Rolle als Software-Architekt an?
Hanna Prinz: Meiner Meinung nach ist es wichtig, dass Architekten möglichst nah am Team sind und einen guten Draht zu Product Ownern haben. Nur mit regelmäßigem, direktem Austausch über Fachlichkeit, Architektur und Technologien können gute technische Entscheidungen gefällt werden.
Architekten sollten nah am Team sein und einen guten Draht zu Product Ownern haben.
Viele – wenn nicht die meisten – Architektur-Entscheidungen fällen sowieso die Entwickler im Alltag. Umso besser das Team bei Architektur-Entscheidungen involviert und informiert ist, desto besser werden diese Entscheidungen sein und desto weniger erodiert die Architektur.
Welchen Trend in Sachen Software-Architektur findest du momentan besonders spannend?
Hanna Prinz: Ich habe natürlich einen Starken Bias in Richtung Cloud, Kubernetes und Service Mesh. Es fasziniert mich immer wieder, wie beliebt und erfolgreich Microservices sind, obwohl es bis vor kurzem so schwer war, sie zu betreiben, zu kontrollieren und Einblicke in das Gesamtsystem zu gewinnen. In diesem Bereich gibt es ständig neue interessante Ideen und Technologien.
Welches Architekturthema außerhalb der Trends liegt besonders am Herzen und sollte deiner Meinung nach mehr Beachtung finden?
Hanna Prinz: Man kann förmlich dabei zusehen, wie Softwareentwicklung immer dynamischer wird. Es geht häufig darum, schnell handeln zu können, selbst wenn dieser Vorteil auch mit ganz offensichtlichen Nachteilen einher geht. Architektur ist aber etwas, wo diese Dynamik nicht möglich und häufig auch nicht sinnvoll ist. Eine Architektur sollte deshalb nur so viel vorgeben wie unbedingt nötig und genug Raum für kontinuierliche Verbesserung lassen.
Eine Architektur sollte genug Raum für kontinuierliche Verbesserung lassen.
Entscheidungen können nur dann wirklich in Frage gestellt werden, wenn der Aufwand, sie zu ändern, beherrschbar ist. Dieses offene Reflektieren über den Ist-Zustand setzt voraus, dass Alternativen bekannt sind. Im Alltag ist man aber mit den immer gleichen Tools und Ideen konfrontiert. Deshalb brauchen wir Kollaboration und Austausch mit anderen. Meetups, Podcasts, Blogs und Workshops sind ein guter Anfang, aber längst nicht alle Unternehmen ermutigen ihre Entwickler, sich so kontinuierlich weiterzuentwickeln und auszutauschen.
Microservices mit Service Mesh
Du gibst auf dem Software Architecture Summit einen Workshop namens „Anarchie mit Ordnung – Microservices mit Service Mesh.“ Welche Vorteile hat man beim Einsatz eines Service Mesh Tools?
Hanna Prinz: Die Automatisierungs-Werkzeuge, die wir nutzen, sind teilweise schon so unsichtbar geworden, dass wir uns ihrer gar nicht mehr bewusst sind. Erst wenn man einen Container-Orchestrierer wie Kubernetes oder das CI/CD-Tooling wegnehmen würde, würde uns deren Mehrwert auffallen.
Ein Service Mesh fügt einer beliebig großen Microservice-Anwendung essentielle Features hinzu.
Ich denke, dass es im Bereich solcher Automatisierungswerkzeuge noch viel mehr Potential gibt. Ein Service Mesh fügt einer beliebig großen Microservice-Anwendung essentielle Features wie Monitoring, Routing, Circuit Breaking und die Absicherung des Netzwerkverkehrs hinzu – und zwar ohne, dass die Anwendungsentwickler auch nur eine Zeile Code ändern müssen. Der Hype um das Thema ist also durchaus berechtigt.
Neben den vielen Vorteilen: Erkauft man sich dabei auch einige Nachteile?
Hanna Prinz: Selbst die sinnvollsten Veränderungen haben immer den Nachteil, dass es Zeit und Ressourcen kostet, die Veränderung zu evaluieren, zu planen, zu kommunizieren und herbeizuführen. Das trifft auch auf die Einführung eines Service Mesh zu.
Darüber hinaus unterscheiden sich die verfügbaren Service-Mesh-Implementierungen stark – nicht nur im Feature-Umfang und was die Kompatibilität mit anderer Infrastruktur wie Kubernetes angeht, sondern auch in der Benutzbarkeit der API für Entwickler. Der mentale Overhead ist meiner Meinung nach aktuell der größte Nachteil von Service Meshes. Schließlich ist das auch nicht die einzige Veränderung, mit denen die Teams konfrontiert sind.
Ein Service Mesh hat außerdem einen Einfluss auf die Antwortzeit einer Anwendung und auf deren Ressourcenverbrauch. Ich empfehle deshalb immer, einen Benchmark mit der individuellen Anwendung zu machen.
Was ist die Kernbotschaft deines Workshops, die jeder Teilnehmer mit nach Hause nehmen sollte?
Hanna Prinz: Am besten nehmen die Teilnehmer natürlich ein Service Mesh für ihre Microservice-Anwendung mit und setzten es gleich in ihrer Microservice-Anwendung ein?
Es gibt viele gute Gründe für ein Service Mesh, aber auch ein paar dagegen.
Spaß beiseite. Es gibt viele gute Gründe für ein Service Mesh, aber auch ein paar dagegen. Meine Teilnehmer werden den Workshop mit einer Einschätzung verlassen, ob sich ein Service Mesh für ihr Projekt lohnt. Es würde mich wundern, wenn der Großteil keine überzeugenden Gründe dafür sieht. Deshalb, und weil der Markt nicht ganz einfach zu durchschauen ist, wird es auch darum gehen, das richtige Service Mesh Tool auszuwählen. Doch auch wenn ein Service Mesh nicht sofort in die Projekte eingeführt wird, möchte ich die Teilnehmer dazu anregen, darüber nachzudenken, wie (oder ob) typische Service-Mesh-Funktionen wie Monitoring, Resilienz und Sicherheit aktuell umgesetzt sind – oder auch nicht.
Vielen Dank für dieses Interview!
Geschrieben von: Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
